(Sun Microsystems, Inc.)(1997).iso/products/Argus/images/image44.gif)
Decaf (Discretionary Control Augmentation Facility) is
a user-installable system security utility for providing secure execution
of Java applets or other network-borne applications or agents. Decaf is
based on a new security paradigm, called "capabilities"
that supplements standard security mechanisms found in most UNIX® systems
including Solaris 2.x. These standard security mechanisms are based on user
ID and file permission bits. Decaf's revolutionary capabilities-based
security design provides a universal access control mechanism that applies
equally to normal user processes as well as processes running as superuser
or root. Although designed primarily to provide security for
Java, Decaf is in fact a general purpose security mechanism that can be
used wherever sensitive, confidential, or mission-critical data and system
resources must be protected from unauthorized access by individual users
or rogue processes.
In this paper, the term file refers to any file system object (such
as a directory, character device, block device, or named pipe) not just
to a regular file.
The era of networked computing is here. The "net"will increasingly be relied upon in the future to provide not only the data,
but the applications and other processing logic needed to complete computer
processing tasks. The boundaries of the "computer" have now been
extended from the desktop to embrace the department, the corporation, and
indeed the world. Users and processes acting on behalf of users are speeding
around the globe in a dizzying phantasm of electronic activity. In the midst
of all of this frenzied activity lies the lifeblood of individuals and corporations
in this the information age - information!
Sun Microsystems, the company that nearly invented the internet, has now
released a radical new technology - Java - that promises to dramatically
change the computing landscape once again. Java allows programmers to write
efficient, network-centric programs (called applets) which can be downloaded
over a network and execute natively on virtually any computer. "Write
once run anywhere" is the basic theme of Java. Because of the radical
possibilities presented by Java and its associated technologies, it has
been embraced by nearly every major computer company from hardware vendors
to applications software vendors to system utility vendors. Java and/or
similar technologies will soon be woven into the very fabric of worldwide
computing and may even serve as the technology bridge from computing to
telecommunications and broadcasting.
Nevertheless, Java presents unique security challenges for computer users,
systems administrators, and data managers. Java applets are intelligent
computer programs that are downloaded from remote sources to run natively
on a local computer which may store and process a wide variety of sensitive,
confidential, and/or mission-critical data. As the Java language is enriched
and expanded, and as Java support is more tightly integrated into applications
and other locally-hosted programs, Java programmers will have at their disposal
a richer set of tools to write stronger and more powerful Java applets.
This power can be abused by nefarious individuals to write malicious applets
which could be used for invasive and unlawful purposes.
One method of addressing this concern is to register and stamp applets with
digital signatures. Users successfully interrogating these applets will
enjoy a greater level of "assurance" that the applet is benign.
Indeed such an approach would certainly diminish the threat of applets being
intercepted and exchanged while enroute to the destination host. However,
the sheer magnitude of applets that will soon be written and embedded in
web pages and other downloadable documents all over the world suggests that
this approach will at best only partially address the problem. In any event,
nothing would prevent a malicious applet from being stamped with a digital
signature; the signature says nothing about the underlying program.
Another approach would be to strictly limit the functionality of applets
at the virtual engine by restricting the applet's ability to launch processes
or interact with locally-resident applications, operating system, or static
resources. Although this would enhance security, it would at the same time
limit the potential of Java for useful purposes.
Decaf addresses the security challenges of Java by securing the environment
in which applets will execute. Decaf allows the total liberation of the
Java language and the complete integration of Java with locally-resident
applications, operating systems, and utilities.
A decaf-flag is an access control mechanism that
can be used in addition to any other access controls existing on the system,
such as file permission bits, access control lists (ACLs), or mandatory
access control labels. In the Java context, decaf-flags can be used
to restrict access to the system by applets downloaded over the net and
launched from within a network browser (Netscape Navigator, HotJava, etc.).
Conversely, decaf-flags can be triggered by a system administrator
or a system user when a program needs to operate in a restricted environment.
Decaf-flags are attached to processes (to indicate specific permissions
granted to the process) and to files (to indicate the permissions required
by a process in order to access the file). For example, a site could define
a decaf-flag which is named "df_system" to indicate that
a file belongs to the system and requires special handling (access). A site
could also define a decaf-flag named "df_local" to indicate
that a file should only be accessed by users logged in directly to the system
and not by users logged in over a network. If a file was marked with both
the "df_local" and "df_system" decaf-flags, a
process (or applet) would have to carry both flags in order to access the
file.
Access restrictions for decaf-flags follow the standard UNIX model:
read, write, and execute. Thus a process or file has a set of three Decaf
capability sets: its decaf read set, its decaf write set,
and its decaf execute set respectively (these are abbreviated to
DRS, DWS, and DES). The collection of all of the Decaf sets for a specific
process or file is called its decaf domain. The relationship between
the decaf domain, the decaf sets, and individual decaf-flags
is shown in Figure 1.
(Sun Microsystems, Inc.)(1997).iso/products/Argus/images/image202.gif)
If a process attempts to read a file, the process's decaf
read set (DRS) must contain all the decaf-flags contained in
the DRS of the target file. If a process has more decaf-flags than
are needed to access the file, the extra decaf-flags of the process
are ignored. For example, if a file has the decaf domain shown in
Figure 2, a process would have to have the "df_local" decaf-flag
in its DRS in order to access the file for reading, although the process
could have other decaf-flags in its DRS. Similarly, to access the
file for write, a process would have to have at least the "df_system"and "df_local" decaf-flags in its DWS.
Note that decaf-flags have nothing to do with the user ID of the
process accessing the file, nor does it have anything to do with the permission
bits of a file. Decaf-flags are enforced on superuser (root)
processes just as they are on all regular user processes. Also, decaf-flags
are enforced in addition to restrictions resulting from the file's permission
bits. Therefore, a process that has the required decaf-flags to access
a particular file may otherwise be denied access because the permission
bits deny access. Naturally, superuser ignores permission bits, so a superuser
process is restricted only by the Decaf-flag mechanism.
The Decaf product allows a process to operate in one of
two modes: capability access control mode (CAC mode) or standard
access control mode (SAC mode). When a process is operating in SAC mode,
its decaf domain is empty and decaf-flags are never checked
when accessing files. This is the default mode for processes running on
the system and for processes started during the boot sequence. When operating
in SAC mode, the system is no different than the standard operating system.
When a process is running in CAC mode, the system enforces decaf-flag
based security as described above.
When the system boots, all programs are running in SAC mode. A program can
switch into CAC mode, or it can create a child process running in CAC mode.
Once a program is in CAC mode, it cannot revert to SAC mode, nor can it
create a child process running in SAC mode. Decaf-flag access controls
are enforced on all processes running in CAC mode, including those running
as superuser or with privilege. There is no mechanism for a process
in CAC mode to bypass the decaf-flag access controls.
A user logged in to a system using a standard shell program can start up
programs either in SAC mode or in CAC mode. If a network browser was started
in CAC mode, then any process that it creates or any program that it runs
will also be run in CAC mode.
It is also possible for a system administrator to set up a user account
that is forced to start up under Decaf (in CAC mode). In this way, all programs
that the user starts will automatically be run in CAC mode.
This is an excellent mechanism to 'compartmentalize' access among departments
or teams within a network. For instance, every user in the finance department
could be forced to log in through a Decaf-enabled shell set with the decaf-flag
"df_finance". Users in the marketing department could be forced
to log in through a Decaf-enabled shell set with "df_marketing".
Users in finance could manipulate files labelled "df_finance"with total transparency but would be incapable of ever accessing files labelled
"df_marketing" and vice-versa. This is true even if a user, after
logging in, is able to access root permissions. Other than this enforced
security policy, users of these Decaf-enabled systems would detect no difference
in their systems.
There are two aspects to setting the decaf domain
of a file: setting the domain when the file is created, and changing the
domain on an existing file. When a file is created by a process running
in SAC mode, the file is created with an empty decaf domain. However,
when a file is created by a process running in CAC mode, the file inherits
the decaf domain of the process which created it.
Changing the decaf domain of a file is similar to changing the permission
bits on a file. If the user is operating in SAC mode, then the user can
change a file's decaf domain provided that the file is owned by that
user. The superuser running in SAC mode can change the decaf domain
of any file on the system. There is no restriction on what decaf-flags
a user can set on a file.
There are a few additional restrictions on changing decaf domains
if the process is running in CAC mode. As under SAC mode, a file's decaf
domain can only be changed by the file owner or the superuser. While
in CAC mode however, the process must also have the appropriate decaf
write set which permits write access to the file, and the decaf-flag
of the file can only be made more restrictive, that is, decaf-flags
cannot be removed from the file's decaf domain.
There is one additional restriction imposed on changing the decaf domain
of a file. The decaf domain on a file can be marked as "locked"by either the superuser or the owner of the file. Once a file's decaf
domain has been locked, its decaf domain cannot be changed or
unlocked except by a superuser running in SAC mode. This means a user could
lock his or her files and be unable to unlock them without superuser assistance.
Using Decaf
Once your system has been upgraded with Decaf, what can
you do? To begin with, simply decide what resources need to be protected,
from whom, and under what circumstances. Resources you may want to protect
are system data files (e.g., the password file), devices (e.g., /dev/kmem),
programs (e.g., shutdown), directories (e.g., /etc/security),
sensitive data files and important site databases. You may decide you have
two classes of users, for example, internal users and guests. You may decide
that you want to restrict access via network programs, such as rlogin,
rsh, ftp, and telnet. You may choose to have
individual users manage their own Decaf environments.
The problem with a network browser that can run downloaded
applications (such as Java applets) is that the applet will run with all
the privileges of the user. Any file the user tries to make inaccessible
via permission bits can be made accessible by the application running with
the user's ID.
Using Decaf however, a user could mark files, directories, or devices with
a decaf-flag called "df_no_Java" and then start the network
browser in Decaf (CAC) mode without the "df_no_Java" decaf-flag.
Neither the browser nor any applet launched through it could ever switch
out of CAC mode or set the "df_no_Java" decaf-flag in its
decaf domain. Accordingly, no applet, launched through the browser
could ever gain access to the protected ("df_no_Java") resources.
The user could exercise great flexibility in setting flags on files, directories,
and other resources. For instance, he could allow the browser "read
access" but not "write access" to certain files while others
have "write" but not "read", and so on. Certain directories
and files including the user's home directory; the .profile, .login
files, and .netrc files; and user-owned executables in the user's
path are so critical that an unintended modification could open the user's
account to outside attackers. These critical resources could be protected
by the decaf-flag mechanism to eliminate the threat of malicious
modification from network-borne agents.
Another key use of Decaf is in designating certain users
as belonging to a restricted class. A copy of the shell program could be
made with the capability "set-on-exec" enabled. Users given this
shell as their login shell would never be able to operate on the system
outside of CAC mode, even if they were able to run setuid programs on the
system. These users could be prevented from accessing certain directories,
files, and programs that were deemed to be off-limits to them and were therefore
set with decaf-flags that are inconsistent with the users decaf-flag
profile which was 'forceably inherited' on log in.
A key concern of system administrators is how to protect
the systems under their charge from malicious outside users. A major problem
in this area regards the fact that network daemons used for allowing access
from a remote site are usually running with superuser privilege.
Flaws in the system configuration or in the programs themselves can often
allow a hostile intruder to damage the system or to reconfigure it to allow
surreptitious access at a later date.
Using Decaf, an administrator can start a network daemon in CAC mode, granting
access only to a limited set of system resources. Some daemons are notorious
for having security holes, and yet need access to only a small number of
directories and files on the system.
For example, the sendmail daemon is a program that accepts a connection
with a remote machine, receives incoming mail, and deposits the mail in
the appropriate user's mailbox. Sendmail operates by accepting
commands from a remote host, and executes those commands on the local machine.
In fact, a user can directly connect to a remote machine's sendmail
server and carry on an interactive session with the daemon! The main
problem with this is that sendmail runs as superuser, and can be
used to create and modify files on the local machine that are not related
to mail delivery and which can be used later to compromise the system. If
sendmail were running in a Decaf environment, the site administrator
could limit the files that sendmail could read or modify so that
such security weaknesses could not be exploited.
Decaf is a general purpose solution to a variety of security
problems. By forcing a user, application, or daemon to operate in a restricted
environment, many security concerns vanish. In addition, the fact that Decaf
access controls are enforced on superuser means that an administrator can
protect the system from system processes or daemons that may have exploitable
security holes. Using Decaf, users can also set up restricted environments
and run programs in the these environments. Unlike standard UNIX, a user
can build an environment where the user is protected from hostile users
and even from himself (improper configuration). Since Decaf runs without
daemons, databases, or extra overhead (the performance impact is too small
to be measured), it is ideal for any environment or system.
Decaf is a revolutionary approach to security, and represents the first
major change to UNIX security in over two decades.
Argus believes that Decaf will lay the security foundation
that will allow the Java programming language to truly flourish and to achieve
the paradigm-shifting promise that it represents.